The development of the EDVAC computer system of 1948 is often cited as the beginning of the computer era. Since that time, computer systems have evolved into extremely sophisticated devices, and computer systems may be found in many different settings. Computer systems typically include a combination of hardware, such as semiconductors and circuit boards, and software, also known as computer programs. As advances in semiconductor processing and computer architecture push the performance of the computer hardware higher, more sophisticated and complex computer software has evolved to take advantage of the higher performance of the hardware, resulting in computer systems today that are much more powerful than just a few years ago.
Years ago, computers were isolated devices that did not communicate with each other. But, today computers are often connected in networks, such as the Internet or World Wide Web, and a user at one computer, often called a client, may wish to access information at multiple other computers, often called servers, via a network. Accessing and using information, e.g. data, services, or other resources, from multiple computers is often called distributed computing.
A client typically accesses data and requests services at a server via a mechanism known as a “connection.” Establishing (or opening) a connection at the server typically involves the setting up of resources (such as computer memory and buffers) so that a particular object, such as a database or file, can be read or written to. The server allocates these resources to a particular connection identified by a connection identifier. Requests from the client to the server include the connection identifier, and the server uses the resources associated with the connection identifier to process the requests. Once the connection is no longer needed, the client sends a close (or release) connection command to the server, which causes the server to close the connection and deallocate the associated resources.
Establishing a connection is expensive in terms of time and performance, so clients often use a technique called “connection pooling,” which reuses connections instead of closing them, in order to avoid re-establishing connections. Under connection pooling, the client opens or establishes a number of connections and adds them to a pool of available connections, which various applications at the client share. When an application is done using a connection, instead of closing the connection, the client returns the connection to the available pool, which another application may then use. The overhead of closing the connection and re-opening another connection when needed is thus avoided, which improves performance of the requests.
While connection pooling has advantages, it has also has disadvantages. The longer that a connection remains in the available pool unused, the more likely that the connection will be stale and unusable when the connection is eventually needed. Connections can become stale for a variety of reasons, such as the server encountering an error, the service or data source on the server encountering an error, or the server noticing that the connection has not been used recently and, in response, closing the connection to free up the associated resources for use by another client.
Since not just individual connections but the entire pool of connections may become stale, detecting and recovering from stale connections is important, and several techniques have been used. A passive technique for managing stale connection is for the client to remove only those connections from the pool that the client actually detects are stale when the client attempts to use the connections. Unfortunately, if all of the connections in the pool are stale, the client must individually attempt to use each connection, detect that each connection is stale, and then remove each connection, which decreases performance. The worst case scenario of all connections being stale can frequently occur if all connections in the pool are for a single server because if that single server is powered off or has encountered an error, all its connections become stale.
In contrast to the passive technique, using an active technique for handling stale connections, the client detects that one connection in the pool is stale while using that connection, and in response proactively investigates all the connections in that pool prior to their use. This active technique has the problem that the client is potentially investigating connections that are good (in the worst case, every connection in the pool is good except for the one stale connection), which decreases performance with unnecessary work. The more connections per pool, and the more servers that are represented in the pool, the worse the active technique performs. Thus, neither the passive nor the active technique provides good performance in all scenarios.
What is needed is a better technique for managing stale connections in a connection pool.